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The  purpose  of  this  study  is  to  develop  a structure  for  a 
methodology  to  produce  a set  of  promising  candidate  architectures. 

This  methodology  incorporates  subjective  considerations  with 
objective  ones  to  control  the  generation  of  architectures  from 
the  complete  space  of  alternatives.  Four  distinct  phases  are 
identified  as  the  logical  divisions  in  this  development  from  a 
purely  conceptual  stage,  based  on  users'  requirements,  to  the 
stage  where  the  components  of  a network  have  been  defined  within 
the  context  of  a practical  network  architecture.  Conceptual  models, 
called  logical  architectures,  are  the  plausible  sequences  of  functions 
which  are  synthesized  via  a regular  grammar  (or,  equivalently,  an 
automation  model)  in  Phase  X.  In  Phase  II,  hierarchical  structure 
is  added  to  the  logical  architecture . Phase  III  is  devoted  to  the 
development  of  the  system  architectures  which  are  used  in  Phase  IV 
to  define  network  elements  and  to  provide  a framework  for  consideration 
of  implementation  issues,  policy  matters,  and  strategies.  This  frame- 
work guides  the  detailed  definition  of  the  candidate  communications 
networks . 
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I.  INTRODUCTION 


The  development  of  an  architecture  for  the  Integrated  Autodin 
System  (IAS)  of  the  1990s  requires  that  many  technical,  engineering, 
functional  and  policy  factors  be  included.  The  state  of  technology 
must  be  forecast  years  in  advance.  The  type  of  system  users  and  the 
services  they  will  need  in  the  next  two  decades  must  be  considered. 

The  constraints  on  cost,  performance,  and  survivability  must  be  de- 
fined. All  these  factors  indicate  that  many  projections,  judgments, 
and  nonquantifiable  requirements  will  be  involved  in  the  development 
of  a preferred  or  optimal  architecture  for  the  IAS  alonq  with  those 
requirements  which  can  be  quantified.  The  purpose  of  this  report  is 
to  describe  an  architecture  development  methodology  which  incorporates 
subjective  considerations  within  a structure  that  permits  the  selection 
of  the  best  candidate  architecture. 

The  main  objective  of  this  methodology  is  to  allow  all  possible 
IAS  1990  architectural  alternatives  to  be  considered  in  an  effective 
and  efficient  manner.  The  methodology  presented  in  this  report  is 
explicitly  designed  to  permit  the  inclusion  of  technical  and  engineer- 
ing value  judgments  as  well  as  well-defined  relationships  and  char- 
acteristics. The  approach  begins  with  the  highest  logical  and  functional 
considerations — the  abstract  aspects — and  proceeds  to  more  tangible 
aspects  through  a sequence  of  four  phases.  Each  phase  identifies  de- 
cisions that  have  to  be  made,  examines  their  inter-relationships,  and 
incorporates  them  in  a controlled  synthesis  of  alternatives.  In  this 
way,  the  number  of  alternatives  considered  in  each  phase  is  minimized. 

The  methodology  is  used  to  produce  a set  of  candidate  architecture 
alternatives.  These  can  be  evaluated  in  more  detail  to  determine  a 
final  selection  on  the  basis  of  forecasted  cost  and  performance  capa- 
bilities. The  methodology  permits  the  determination  of  alternatives 
without  the  enumeration  of  all  possibilities.  The  tools  used  to  develop 
and  select  architectural  alternatives  include  the  theory  of  regular 
structures  and  dynamic  programming  techniques. 

The  report  consists  of  four  chapters.  Chapter  II  is  a discussion 
of  the  services,  functions  and  performance  considerations  which  are 
critical  to  the  IAS  architecture  development.  Chapter  III  is  a de- 
scription of  the  methodology  in  general  and  each  of  the  phases  within 
the  methodology.  Chapter  IV  is  a summary  of  the  major  features  of  the 
methodology. 


II.  IAS  FUNCTIONAL  BASELINE 


I.  INTRODUCTION 

Before  proceeding  with  the  IAS  architecture  development  process, 
it  is  important  to  identify  the  services  and  capabilities  required  of 
the  system,  and  translate  these  into  a functional  baseline  which  will 
serve  to  guide  the  generation  of  feasible  architectures.  The  IAS  must 
possess  certain  basic  capabilities  in  order  to  satisfy  its  objectives. 

In  broad  terms,  the  system  must  provide  end-to-end  record  and  data 
communications,  as  well  as  teleprocessing  and  resource  sharing  services, 
to  a wide  variety  of  DOD  subscribers.  In  addition  to  these  fundamental 
capabilities,  the  requirements  of  the  IAS  users  are  met  by  a variety  of 
service  features.  Services  are  offered  in  response  to  established  or 
projected  needs  for  increased  performance  and  efficiency  in  specific 
operations  carried  out  by  a community  of  users. 

The  aggregate  of  capabilities  and  services,  together  with  detailed 
information  transfer  requirements  constitute  the  IAS  requirements  base- 
line. This  in  turn  translates  into  the  functional  baseline  (Figure  1), 
an  important  input  to  the  architecture  development  methodology.  The 
functional  baseline  consists  of: 

Necessary  Functions  - those  functions  which  support  the 
services  and  capabilities. 

Performance  Parameters  - those  performance  measures,  goals, 
and  constraints,  derived  from  user  and  system  requi rements , 
which  characterize  system  behavior,  provide  evaluation 
criteria,  and  form  the  basis  for  the  rating  and  selection 
of  viable  architectures. 

The  information  on  services  and  functional  requirements  presented 
later  in  this  chapter  is  not  meant  to  be  exhaustive  and  definitive. 
Instead,  it  tries  to  list  those  services  and  functions  which  are  likely 
to  be  present  in  any  IAS  architecture,  together  with  a few  which  are 
somewhat  speculative  in  nature.  This  effort  has  relied  on  a careful 
study  of  existing  systems  (e.g.,  ARPANET,  AUTODIN  I,  TELENET),  and  the 
information  provided  by  several  requirements  definition  studies 
(Refs.  [1]  - [8]). 

For  the  1978-1983  time  frame,  the  services  and  requirements  are 
rather  firmly  established.  For  the  post-1983  time  frame,  however,  the 
forecasting  and  validation  process  is  affected  by  the  rapid  pace  of 
technological  developments,  as  well  as  the  impact  of  major  policy 
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Figure  1.  Functional  Baseline  Derivation 


decisions.  The  IAS  development  effort  must  be  geared  towards  a robust 
design  to  accommodate  these  uncertainties  and  limitations. 

The  parameters  identified  in  this  chapter  should  be  sufficient  for 
the  purpose  of  applying  the  IAS  development  methodology  in  the  genera- 
tion of  viable  long-term  candidate  architectures.  The  requirements 
analysis  will  continue  throughout  the  development  process,  with  refine- 
ments to  the  current  information  performed  as  necessary.  These  refine- 
ments will  update  the  candidate  architecture  designs. 

2.  CAPABILITIES 


In  order  to  accomplish  its  objectives  and  meet  the  user's  basic 
needs,  the  IAS  network  must  possess  several  general  capabilities.  As 
a minimum,  the  system  must: 

a.  Provide  rapid,  reliable  communications  between  subscribers. 

b.  Provide  cost-effective  utilization  of  communications  resources 
to  handle  projected  traffic  loads. 


c.  Provide  secure  communications  throughout  the  system. 

d.  Interface  with  other  networks: 

Military  (WWMCCS,  NTS,  TRI-TAC,  etc.) 

Allied  (NATO) 

Commercial. 

This  interoperability  can  range  from  interfacing  on  a gateway 
level  to  full  integration. 

e.  Provide  cost-effective  and  efficient  utilization  of  hardware 
and  software  facilities  through  resource  management  and  sharing. 


f.  Accommodate  subscribers  with  diverse  codes,  formats  and  speeds. 


g.  Incorporate  a high  degree  of  flexibility;  in  particular: 

(1)  Accommodate  a variety  of  transaction  types,  including: 

Interactive  (I/A) 

Narrative/Record  (N/R) 

Query/Response  ( Q/R ) 

. Bulk  Data  Transfer  (BDT) 

System  Control  (Overhead). 
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(2)  Provide  adaptability  to  future  requirements  and  tech- 
nology developments  through  incremental  modernization. 

(3)  Provide  expandability  through  incremental  and  modular 

growth. 

h.  Accommodate  transactions  with  various  levels  of  priority. 

i.  Accommodate  a variety  of  input/output  media. 

j.  Provide  accountability  of  all  system  transactions. 

k.  Provide  a high  degree  of  transparency  in  user-to-user  and 
user-to-computer  transactions. 

l.  Meet  the  necessary  privacy  requirements  of  the  user  community. 

m.  Provide  the  necessary  maintainability  and  reconfigurabi 1 i ty 
features  to  ensure  continuity  and  quality  of  service. 

3.  SERVICES 

Beyond  the  required  capabilities,  the  IAS  will  offer  additional 
service  features  to  meet  specific  user  needs.  Listed  below  are 
several  services  which  are  candidates  for  inclusion  in  the  IAS  archi- 
tecture in  the  1978-1990  time  frame. 

a.  Narrative/Record  Message  Service.  This  is  the  present  JANAP 
128/ACP  127  formatted  messages  service,  meeting  the  unique  needs  of 
official  message  communications. 

b.  Narrative/Record  Message  File  Retrieval  Service.  This  service 
would  provide  additional  features  to  the  Narrative/Record  Message 
Service,  including  the  ability  for  the  user  to  request  copies  of  pre- 
viously received  or  transmitted  messages.  The  service  would  be  re- 
stricted to  official  communications  and  would  not  attempt  to  be  a 
general  filing  service. 

. 

c.  AUTODIN  Limited  Privacy  Service  (ALPS).  This  service  provides 
the  user  with  a measure  of  privacy  above  that  which  is  available  in  the 
Narrative/Record  Message  Service.  It  ensures  that  no  permanent  record 
of  the  text  content  of  the  message  is  available  at  the  switching  center, 
and  restricts  access  to  it  as  the  message  passes  through  the  system. 

d.  Commercial  Refile  Service.  This  service  allows  the  interchange 
of  record  communications  between  AUTODIN  and  public  data  and  record  net- 
works. 
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e.  Base  Distribution  Service.  This  service  will  be  aimed  at  sat- 
isfying the  needs  of  all  services  for  base,  camp,  and  station  message 
and  data  distribution. 

I 

f.  Digital  FAX  Service.  It  will  provide  facsimile  service  in 
applications  where  the  standard  communications  services  are  inadequate 
to  the  task  being  performed  by  the  user,  and/or  where  the  economics  of 
using  facsimile  clearly  demonstrates  savings  over  more  conventional 
means.  This  service  constitutes  one  version  of  electronic  mail. 

g.  ADP  Teleprocessing  Communication  Services.  These  are  the 
services  which  are  made  possible  by  the  implementation  of  AUTODIN  II. 
The  basic  types  of  transactions  available  in  this  packet  switched 
environment  are: 

(1)  Interactive  (I/A).  The  rapid  exchange  of  information 
between  subscribers  in  a conversational  mode  whereby  the  continuity  of 
the  information  transfer  process  is  maintained  during  the  "session." 

I ! 

(2)  Query/Response  (Q/R).  The  exchange  of  a question  and 
answer  with  no  attempt  to  sustain  the  continuity  of  the  information 
transfer  process. 

(3)  Bulk  Data  Transfer  (BDT).  The  transmission  of  files, 

x programs,  processing  results,  or  data  bases  from  one  computer  to 

. ‘ another  in  bulk  or  block  form  with  transaction  lengths  ranging  from 

10  Kilobits  to  100  Megabits. 

(4)  Narrative/Record  (N/R).  The  transfer  between  subscribers 
of  narrative  messages  in  record  form  in  a character-oriented  format. 

h.  Resource  Sharing  Services.  These  go  beyond  the  teleprocessing 
services  (category  g)  to  include  those  which  increase  the  availability 
of  network  resources  to  the  subscriber  and  enhance  the  cost-effective 
utilization  of  these  resources.  Included  are: 

Load  Sharing 

. Hardware  Sharing 
Data  Base  Sharing 
Program/Software  Sharing. 

i.  Data  Teleconferencing  Service.  This  would  include  data  con- 
ferencing using  keyboards  and  CRT  displays,  and  possibly  a slow  scan 
video  capability. 

j.  Mailbox  Service.  In  this  version  of  an  electronic  mail 
service,  messages  destined  for  action  officers  are  delivered  to  a 
holding  file  on  a host  computer,  where  modification,  redirection. 
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electronic  filing  for  future  reference  and  other  operations  may  be  per- 
formed on  the  data.  The  file  is  accessed  by  the  addressee  at  his 
convenience. 

k.  Word  Processing  Service.  This  service  is  composed  of  automated 
editing  features  and  functions  which  aid  in  the  preparation  of  typed 
material.  If  document  distribution  and  interconnection  between  distant 
subscribers  are  incorporated  into  this  service,  the  result  is  a Commun- 
icating Word  Processor  Service  (CWP),  another  form  of  electronic  mail. 

l.  Computer  Internetting  Service.  By  combining  the  individual 
features  present  in  the  various  networks  associated  with  the  IAS,  de- 
sired sets  of  services  can  be  attained  and  presented  as  "new"  ones. 

m.  Informal  Message  Exchange  Service.  This  service  features  a 
simple  format,  interactive  connection  for  the  passage  of  correspondence. 
Message  accountability  is  the  user's  responsibility.  The  service  would 
be  capable  of  interfacing  with  the  companion  service  of  "Mailbox"  and 
"Word  Processing." 

n.  Manaqement/Financial  Services.  This  would  encompass  a broad 
range  of  accounting,  payroll,  inventory,  and  funds  transfer  services. 

o.  Limited  Digitized  Voice  Service.  This  service,  which  supports 
voice  passage  through  the  network  in  a digital,  encrypted  form,  is  in- 
tended for  use  in  applications  where  the  furnishing  of  voice  as  an 
alternate  to  data  is  an  integral  part  of  the  overall  user  requirement. 

p.  Paging  Services.  This  is  a modification  of  the  commercial 
paging  concept,  using  the  IAS  communications  facilities. 

* * * * 

More  detailed  descriptions  and  information  about  the  above  services 
can  be  found  in  References  [3],  [4],  and  [6]  through  [9]. 

At  present,  services  a through  f have  been  implemented  in  the 
existing  AUTODIN  system  to  some  extent.  In  addition,  the  Teleproces- 
sing and  Resource  Sharing  services  are  in  the  early  stages  of  imple- 
mentation, as  AUTODIN  II  begins  to  take  shape.  The  inclusion  of  the 
remaining  services  (i  through  p)  in  the  IAS  remains  to  be  determined. 
Given  the  current  technological  trends  toward  office  procedure  ano- 
mation,  electronic  mail,  and  teleconferencing,  services  i,  j,  ana  k 
are  likely  offerings  in  the  IAS  network.  Additionally,  the  Computer 
Internetting  Service  could  be  a likely  outgrowth  of  the  IAS  goals  of 
interoperability  and  effective  use  of  network  resources. 

The  above  list  of  sixteen  services  is  not  exhaustive,  but  includes 
those  which  are  currently  under  consideration  for  the  IAS.  While  other 


services,  such  as  telemedicine  and  training,  may  be  added  to  the  IAS 
architecture  in  the  future,  it  is  not  envisioned  that  these  services 
will  require  additional  major  functions  for  their  support  beyond  those 
in  the  current  baseline. 

4.  FUNCTIONS 

In  order  to  support  the  capabilities  and  services  discussed  in 
previous  paragraphs,  the  IAS  architecture  must  include  a wide  range 
of  functions.  These  functions  can  be  categorized  into  three  basic 
areas  for  discussion  purposes;  these  are:  in-line,  auxiliary,  and 
management  and  control.  The  categorized  list  of  functions  is  given 
in  Figure  2. 

The  in-line  category  includes  those  functions  which  are  usually 
in  the  direct  sequence  of  events  when  a basic  unit  of  information  is 
transferred  through  a network  from  one  subscriber  to  another.  These 
functions  are  most  essential  to  the  flow  of  information  within  a net- 
work. 


Auxiliary  functions  are  those  which  are  required  to  support  either 
the  in-line  functions  or  certain  network  services.  Unlike  the  in-line 
functions,  the  auxiliaries  are  not  directly  encountered  by  a trans- 
action flow  through  the  network. 

Management  and  control  functions  are  those  functions  which  are  re- 
quired to  maintain  and  control  order  in  a communication  system.  They 
include  the  functions  required  to  control  the  flow  of  information,  to 
allocate  the  hardware  and  software  resources  in  the  network  and  to 
perform  the  monitoring  and  data  processing  required  for  system  perform- 
ance assessment. 

As  indicated  earlier  in  this  chapter,  the  services  and  capabilities 
offered  by  the  IAS  architecture  translate  into  necessary  functions. 

This  translation  process  involves  careful  study  of  each  service  and 
capability  to  determine  which  functions  are  required  to  support  it. 

The  relationship  is  not  one-to-one.  That  is,  a service  might  require 
several  functions;  conversely,  a single  function  might  support  a variety 
of  services.  The  derivation  of  functions  from  IAS  capabilities  is 
illustrated  in  Figure  3.  Only  those  functions  which  are  most  immediately 
derived  from  a capability  are  shown.  Similarly,  Figure  4 illustrates 
the  derivation  of  functions  from  a representative  sample  of  IAS  services. 

Given  the  wide  range  of  functions  which  support  the  IAS  architecture, 
as  well  as  the  functional  similarities  among  services,  it  is  very  likely 
that  the  implementation  of  additional  services  will  require  only  minor 
changes  in  the  functional  make-up  of  the  architecture. 
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In-Line 


1 

,1 


El 


Auxiliary 


Management  & Control 


Address  Generation 
Address  Conversion 
Access  Control 
Local  Distribution 
External  Network  Interface 
Switching 

Red/Black  Conversion 
Black/Red  Conversion 
Transaction  Preparation  Assistance 
(e.g.,  prompting,  editing,  formatting) 
Concentration 
Multiplexing 
Speed  Conversion 
Code  Conversion 
Format  Conversion 
Mode  Conversion 


Transaction  Storage  & Retrieval 
Transaction  Readdressal 
Transaction  Editing  & Reformatting 
Data  Storage  & Retrieval 
User  Identification/Verification 
Multiple  Delivery 
Data  Base  Maintenance 


Network  Control 
Network  Management 
(e.g.,  statistics,  billing, 
resource  allocation) 
Journaling 

Traffic  Control  & Routing 
Status  Monitoring 
System  Security 

(e.g.,  key  variable  distribution, 
security  processing) 


Figure  2. 


Categories  of  Functions 
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CAPABILITY 

FUNCTIONS 

Rapid,  reliable 
communications 

. Routing 
. Switching 
. Local  distribution 
. Error  control 

Cost-effective  utilization 
of  communications  resources 

. Concentration 
. Multiplexing 

Cost-effective  and  efficient 
utilization  of  hardware 
and  software  facilities 

. Network  management  and 
control 

Secure  communications 

. Encryption/decryption 
. Key  variable  distribution 
. Access  control 
. Verification 

Acceptance  of  diverse  codes, 
formats  and  speeds 

. Code  conversion 
. Format  conversion 
. Speed  conversion 

Figure  3.  Sample  Derivation  of  Functions 
From  IAS  Capabilities 
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SERVICE 

FUNCTIONS 

Narrative/Record  Message 

. Transaction  Preparation 
Assistance 

. Local  Distribution 
. Plain  Language  Addressing 

Mailbox 

. Data  Storage  & Retrieval 
. Edit  Messages  on  File 

Word  Processing 

. Data  Storage  & Retrieval 
. Standard  Forms  Storage  & 
Recal 1 

Resource  Sharing 

. Network  Management 
. Resource  Access  Control 
. Precedence/Preempt 

Computer  Internetting 

. Protocol  Conversion 
. Traffic  Control  & Routing 

5.  PERFORMANCE  PARAMETERS 


The  performance  parameters  are  useful  to  determine  how  well  the 
system  supports  the  required  capabilities  and  services.  They  character- 
ize the  system  behavior  under  anticipated  operating  conditions.  Addi- 
tionally, they  are  used  to  evaluate  systems  with  respect  to  predetermined 
performance  requi rements.  At  the  detailed  design  and  implementation 
level,  the  use  of  quantitative  and  explicit  performance  measures  is 
appropriate.  These  measures  are  derived  from  the  performance  parameters. 
At  the  system  concept  and  logical  level,  however,  performance  parameters 
are  used  in  a qualitative  way. 

Performance  parameters  fall  into  two  major  categories: 

. User-Motivated  - those  derived  directly  from  the  operational 
requirements  of  the  subscribers. 

System-Motivated  - those  which  arise  from  system  requirements. 
System  requirements  are  relatively  transparent  to  the 
individual  users.  They  are  derived  from  the  need  to 
provide  an  organizational  framework  to  support  user 
requirements. 

The  most  common  parameters  are  listed  below. 

a.  User-Motivated  Parameters 

(1)  Response  Time.  Broadly  defined  as  the  time  the  system 
takes  to  respond  to  a given  input,  this  parameter  must  be  described  in 
statistical  terms.  In  the  absence  of  a precise  distribution  function, 
maximum  tolerable  values,  as  well  as  mean  and  variance,  may  be  specified. 
Depending  on  the  type  of  transaction  being  considered,  response  time 
can  take  on  two  meanings: 

Interactive  Response  Time  - also  referred  to  as 
"turnaround  time,"  this  measure  of  responsiveness 
is  applicable  when  operating  in  a "conversational" 
environment.  It  is  defined  as  the  time  interval 
between  the  completion  of  the  transaction  entry  at 
a terminal  and  the  point  when  the  system  response 
first  appears  at  this  terminal. 

Delivery  Time  - this  parameter  is  used  when  the  in- 
formation transfer  is  primarily  unidirectional,  as 
in  record  transmission  or  file  transfers.  It  is 
defined  as  the  time  interval  between  the  start  of 
transmission  at  the  sending  location  and  the 
completion  of  reception  at  the  receiving  station. 
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(2)  Availability.  This  is  the  probability  that  the  network 
will  provide  the  service  required  by  a user  at  any  given  time.  The 
wide  variety  of  resources  in  the  IAS  network,  as  well  as  the  distinct 
nature  of  each  user's  service  demands,  suggest  descriptions  of  partial 
availability.  In  general,  availability  is  closely  tied  to  system 
reliability.  For  this  reason,  availability  calculations  frequently 
incorporate  reliability  measures  (such  as  mean  time  between  failures). 
The  two  principal  aspects  of  availability  are: 

Connection  Time  - involves  the  probability  of 
obtaining  access  to  the  system  within  a given  time 
interval . 

Service  Continuity  - involves  the  probability  of 
obtaining  uninterrupted  service. 

(3)  Data  Integrity.  This  parameter  is  concerned  with  the 
errors  which  can  occur  in  the  transfer  of  information  between  sending 
and  receiving  locations.  It  is  usually  specified  in  terms  of  distribu- 
tions and  rates  which  are  categorized  according  to  the  nature  of  the 
information  transfer  and  the  source  of  errors. 

(4)  Subscriber  Throughput.  This  performance  parameter  is 
concerned  with  the  data  rates  the  system  can  provide  in  support  of 
user-oriented  transactions.  The  characterization  of  throughput  should 
be  statistical  and  provide  peak  and  average  values,  as  well  as  daily 
and  "busy  hour"  traffic  distributions. 

(5)  Cost.  This  parameter  deals  with  the  various  subscriber 
costs.  These  include  hardware,  software,  communications,  services, 
growth  and  expansion,  etc. 

b.  System-Motivated  Parameters 

(1)  Reliability.  Generally  speaking,  this  is  the  probability 
that  the  system  will  perform  its  function  prope?  ly  under  specified 
operating  conditions.  Reliability  analysis  must  take  into  account 
failures  of  various  types  (hardware,  software,  transmission,  etc.)  as 
well  as  the  resulting  system  degradation  and  the  system  recovery  capa- 
bilities. With  the  knowledge  of  network  topology  and  expected  component 
lifetime,  a wide  variety  of  reliability  measures  can  be  formulated  and 
specified  statistically  (Refs.  [10]  - [13]).  Three  typical  measures 
are: 

. The  probability  of  a disconnection  occurring  between 
any  pair  of  subscribers. 

. Mean  time  between  failure  (MTBF)  and  expected  repair 
time. 

. Fault  detection/diagnostic  delays. 
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(2)  Survivability.  This  parameter  involves  the  degree  to 
which  services  can  be  retained  or  rapidly  restored  after  disruption  by 
natural  calamity  or  by  enemy  action.  Survivability  analysis  must  con- 
sider system  threat  operational  procedures,  as  well  as  vulnerabilities 
of  network  elements  and  resources  to  various  threats.  Survivability 
and  reliability  deal  with  many  common  issues  and  rely  on  similar  anal- 
ysis and  performance  statistics  (Refs.  [14],  [15]).  Some  typical 
measures  of  survivability  are: 

Average  number  of  subscribers  able  to  communicate 
after  a failure. 

Reconfiguration  and  recovery  time. 

Expected  network  throughput  under  a threat 
environment. 

(3)  System  Throughput.  This  parameter  describes  the  overall 
data  transfer  capacity  of  the  network,  which  takes  into  account  both 
user-oriented  transactions  and  computer-generated  traffic.  Throughput 
statistics  should  be  specified  according  to  traffic  type,  time  of  day, 
etc. 


(4)  Resource  Utilization.  This  describes  the  degree  to  which 
an  architecture  makes  efficient  and  effective  use  of  its  resources. 
Attention  should  be  given  to: 

Channel  utilization 

Load  leveling 

Potential  network  "bottlenecks" 

Utilization  of  shared  resources  (ADP,  data  bases, 
service  facilities,  etc.). 

(5)  Cost.  A wide  variety  of  issues  are  dealt  with  in  terms 
of  cost.  Some  of  the  engineering  management  considerations  likely  to 
be  addressed  in  the  IAS  are: 

. Development  and  implementation  costs 
Operations  and  maintenance  costs 

. Development  risks  associated  with  technology 
forecasting  and  assessment 

Difficulty  and  cost  associated  with  evolutionary 
implementation  of  the  system 
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Hardware,  software,  and  communications  costs 
Hardware/ software  trade-offs 
Cost/complexity  trade-offs 
Life  cycle  cost  studies. 
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III.  METHODOLOGY  FOR  DEVELOPING  ARCHITECTURES 


1.  INTRODUCTION 

This  chapter  outlines  a methodology  for  identification  and 
definition  of  the  feasible  set  of  IAS  architectures.  The  functions 
and  performance  parameters  discussed  in  the  previous  chapter  drive 
the  methodology  which  synthesizes  a complete  space  of  possibilities. 
These  possibilities  are  the  feasible  architectures.  Moreover,  this 
methodology  provides  a framework  for  subjective  judgments  and  it 
produces  a manageable  number  of  promising  architecture  candidates. 

After  consideration  of  the  architecture  development  process,  four 
distinct  phases  were  identified  as  the  logical  divisions  in  this 
development  from  a purely  conceptual  stage,  based  on  users'  require- 
ments, to  the  stage  where  the  components  of  a network  have  been  de- 
fined within  the  context  of  a practical  network  architecture.  The 
performance  parameters  are  used  qualitatively  and  quantitatively  to 
guide  the  synthesis  of  the  alternatives  in  each  phase.  This  controls 
the  number  of  alternatives  produced. 

The  four  distinct  phases  are  the  development  of  (1)  logical  arch- 
itectures, (2)  functional  architectures,  (3)  system  architectures, 
and  (4)  network  architectures.  In  Phase  I,  the  synthesis  of  logical 
architectures,  several  of  the  functions  in  Figure  2 are  used  to  con- 
figure a set  of  architectures  which  represent  plausible  sequences  of 
required  functions.  They  are  called  logical  architectures  because 
they  do  not  include  references  to  physical  or  system  level  functions, 
but  rather  model  the  flow  of  information  and  the  functions  encountered 
by  the  transaction  flow  between  users. 

The  functional  archi Lectures  consist  of  stratified  logical  arch- 
itectures augmented  by  additional  functions.  The  stratification 
consists  of  the  hierarchical  grouping  of  functions  in  the  logical 
architecture.  The  added  functions  are  selected  from  the  list  in 
Figure  2 and  they  serve,  in  part,  to  support  the  Phase  I functions. 
These  steps  comprise  Phase  II. 

The  system  architectures  are  developed  in  Phase  III.  They  are 
the  functional  architectures  integrated  with  the  system  level  functions 
(e.g.,  security,  management  and  control,  etc.)  and  with  physical  en- 
vironment factors.  System  elements  are  postulated  from  this  integra- 
tion as  groupings  of  functions;  they  are  defined  in  terms  of  their 
functional  responsibilities  and  their  logical  interconnection. 

Phase  IV  is  the  definition  of  network  architectures.  A network 
architecture  is  a system  architecture  which  has  been  defined  in 


III-l 


sufficient  detail  to  form  the  basic  structure  of  a communications  net- 
work. The  network  elements  are  defined  on  the  basis  of  the  system 
elements  identified  in  Phase  III.  Objectives  of  Phase  IV  include 
selection  of  an  optimal  interconnection  policy  and  identification  of 
protocol  structures  and  routing  strategies  for  each  alternative.  The 
optimal  architectural  candidates  (with  respect  to  the  performance 
parameters)  can  be  determined  from  these  alternatives  by  application 
of  selection  criteria  based  on  analysis,  modeling  and  simulation. 

2.  PHASE  I - LOGICAL  ARCHITECTURES 

a.  Definition.  Logical  architectures  are  defined  as  organiza- 
tions and  combinations  of  functions  which  are  independent  of  network 
hierarchy  or  physical  implementation.  A logical  architecture  repre- 
sents an  arrangement  of  functions  which  are  necessary  for  the  basic 
process  of  communication  to  take  place.  Most  of  these  functions  are 
listed  as  the  in-line  functions  in  Figure  2.  A typical  set  is  given 
in  Figure  5. 

b.  Generation  and  Selection.  The  total  number  of  possible  organ- 
izations is  not  practical  to  enumerate  even  in  the  case  of  a moderate 
number  of  functions.  Moreover,  this  enumeration  would  contain  many 
inadmissible  architectures.  The  inadmissible  architectures  would  be 
those  which  violate  constraints.  These  constraints  include  engineering 
judgment,  practices,  technological  realities,  and  predictions.  For 
example,  the  "address  generation"  function  must  precede  "external  net- 
work interface"  (gateway  functions). 

The  description  of  the  logical  architectures  should  proceed  in 
two  ways.  One  way,  a restrictive  production,  is  to  generate  all 
possible  configurations  of  functions  and  then  single  out  those  which 
satisfy  constraints.  Construction  of  an  efficient  algorithm  to  sift 
through  this  enumeration  of  all  possible  organizations  appears  to  be 
difficult.  For  this  reason  the  second  way,  a generative  description, 
is  the  approach  taken.  The  constraints  are  translated  into  structural 
rules,  called  generators,  which  generate  the  logical  architectures. 

That  is,  the  generators  specify  admissible  combinations  of  functions. 
This  provides  the  organizational  means  to  deal  with  the  necessary  com- 
binations which  make  up  the  set  of  viable  architectures.  The  benefits 
from  this  approach  include  a checklist  feature,  rigor,  and  completeness. 
That  is,  all  functions  can  be  accounted  for  in  this  formal  system  to 
generate  as  complete  a set  of  logical  architectures  as  is  possible. 

A generation  and  selection  procedure  which  reduces  the  number 
of  possible  organizations  to  be  considered  would  be  desirable.  The 
selection  is  based  on  the  rank  order  of  logical  architectures.  It  is 
possible  to  introduce  a system  of  weights  on  the  generators  which  is 
consistent  with  a preference  rank  order.  Once  these  weights  are 
assigned  to  the  generators,  the  optimal  viable  architectures  are 
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FUNCTION 


Access  Control 

Address  Generation 

Address  Conversion 

Local  Distribution,  Incoming 

Local  Distribution,  Outgoing 

External  Network  Interface 

Switching 

Red/Black  Conversion 

Black/Red  Conversion 

Transaction  Preparation 
Assistance 


produced  by  application  of  dynamic  programming.  Dynamic  programming 
also  provides  the  means  to  a sensitivity  analysis.  This  uses  the 
parameters  and  the  computational  work  that  defined  the  original  solu- 
tion to  produce  new  solutions  for  ranges  in  the  parameters.  In  this 
way,  a manageable  number  of  promising  logical  archi tectures  is  generated 
efficiently. 

The  generation  process  is  developed  and  uses  concepts  from 
the  mathematical  theory  of  regular  structures.  (The  terminology, 
concepts,  and  notation  are  described  briefly  in  Appendix  A.  A more 
complete  development  can  be  found  in  Reference  [16].)  This  formal 
scheme  is  a rigorous  framework  which  specifies  the  constrained  com- 
binatory system  as  a weighted  grammar.  This  rigor  provides  a means 
to  analyze  the  sensitivity  of  logical  archi tectures  to  changing 
(modified,  added,  or  deleted)  requirements.  This  scheme  and  the  dy- 
namic programming  techniques  are  automatable.  This  is  important  to 
the  methodology  because  of  the  number  of  functions  and  the  potential 
for  a combinatorially  large  number  of  possible  architectures. 

c . Example  of  the  Logical  Architecture  Generation  Procedure.  An 
example  is  presented  in  this  section  to  clarify  the  formal  notions.  The 
presentation  is  informal  so  that  the  technical  aspects  of  algebra  and 
the  detail  of  networks  do  not  interfere  with  the  illustration.  The 
functions  used  in  this  example  are  presented  in  Figure  5.  They  are 
labeled  for  ease  of  reference. 

Before  the  generators  are  identified,  it  is  useful  to  identify 
any  precedence  and  concurrence  relations  among  the  functions.  A pre- 
cedence relation  indicates  which  function  must  precede  another  one. 

The  concurrency  relation  indicates  which  functions  can  be  logically 
concurrent  with  respect  to  a transaction  flow.  These  relations  are  con- 
veniently represented  in  matrix  form  and,  for  the  sample  functions,  this 
matrix  appears  in  Figure  6.  These  relations  are  based  on  the  constraints. 
The  relations  are  checked  for  consistency  and  then  analyzed  for  the 
structural  inter-relationship  among  the  functions.  This  analysis  pro- 
duces the  stratification  for  each  function;  it  gives  the  number  of  suc- 
cessors. For  example,  functions  f,,  f7,  and  f„  have  one  or  two.  The 
generators  are  derived  from  this  analysis.  They  consist  of  terminals 
(functions)  and  non-terminals  (denoted  by  1,2,...).  The  process  begins 
by  application  of  a generator  for  the  "start"  symbol,  or  axiom,  which 
is  denoted  by  "1."  It  continues  by  rewriting  (replacement  of)  the  non- 
terminals until  a tree  containing  only  terminals  remains.  A represent- 
ative set  of  generators  and  the  three  logical  architectures  they  define 
are  presented  in  Figure  7. 

3.  PHASE  II  - FUNCTIONAL  ARCHITECTURES 

a.  Definition.  The  second  phase  of  the  methodology  is  the  con- 
struction of  functional  architectures.  The  functional  architectures 
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consist  of  stratified  logical  architectures  augmented  by  additional 
functions.  The  stratification  consists  of  the  hierarchical  grouping 
of  functions  in  the  logical  architecture.  In  addition  to  these  func- 
tions, there  will  be  other  functions  included  in  Phase  II  which  are 
not  included  in  Phase  I because  they  are  either  not  in-line  functions 
or  more  implementation  dependent.  A list  of  such  functions  is  given 
in  Figure  8.  Functional  architectures  are  a step  closer  to  the  physi- 
cal environment  but  do  not  depend  on  any  specific  network  implementation. 

b.  Stratification  and  Augmentation.  A hierarchy  is  a ranking, 
ordering  or  grouping  into  a sequence  of  subordinate  levels.  There 
are  several  factors  on  which  the  grouping  of  functions  into  a hierarchy 
can  be  based.  A fundamental  factor  is  the  logical  relationship  that 
exists  among  the  functions.  The  stratification  should  not  re-order  a 
logical  architecture. 

The  number  of  functions  in  each  grouping  and  the  level  to 
which  the  grouping  is  assigned  might  depend  on  physical  implementation 
and  technical  feasibility  of  such  groupings.  It  is  assumed,  of  course, 
that  the  use  of  functional  hierarchies  will  not  constrain  the  inter- 
connections between  network  elements,  as  defined  in  a later  phase,  for 
achieving  required  performance,  survivability  and  availability. 

Where  a large  number  of  users  sha^e  a common  communications 
network,  at  least  two  hierarchical  levels  naturally  exist:  the  level 
which  contains  the  individual  users  and  the  shared  portion  of  the  net- 
work. The  shared  level  may  include  a switched  system  or  may  consist 
of  only  the  transmission  facilities  that  interconnect  the  users.  In 
large  networks,  a third  level  is  usually  desirable  for  economic  sharing 
of  resources  and  conserving  transmission  facilities.  Phase  II  of  the 
methodology  will  therefore  consider  the  possibility  of  at  least  three 
hierarchical  levels. 

The  lowest  hierarchical  level  corresponds  to  a local  area  and 
includes  users  and  user  terminals.  No  strict  definition  of  what  con- 
stitutes the  geographical  extent  of  a local  area  will  be  advanced  in 
Phase  II.  Such  a definition  depends  on  transmission  media,  which  is 
a physical  factor  not  considered  until  later  phases  in  the  methodology. 

The  second  level  corresponds  to  what  could  be  called  a regional 
area.  It  would  be  broader  in  scope,  extent  or  functional  responsibility 
than  the  lowest  level.  Again,  no  geographical  description  or  definition 
of  a second  level  will  be  made  in  this  phase  but  will  be  held  off  until 
a later  phase  when  the  more  physical  characteristics  are  addressed. 

The  third  level  or  highest  level  will  include  those  functions 
which  can  be  performed  on  the  broadest  or  most  general  scale.  This 
level  is  an  obvious  analogue  to  the  familiar  "backbone"  level  in  net- 
work design.  However,  the  term  backbone  connotes  switching  and  will 
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LABEL 


FUNCTION 


H1 

Transaction  Storage  & Retrieval 

H2 

Transaction  Readdressal 

H3 

Transaction  Editing 

H4 

Journaling 

H5 

Data  Storage  & Retrieval 

H6 

Speed  Conversion 

H7 

Code  Conversion 

H8 

Format  Conversion 

h9 

User  Identification/Verification 

« 


Figure  8.  Phase  II  Functions 
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not  be  used  in  the  following  discussion  about  methodology  to  avoid  any 
confusion.  While  the  switching  function  is  certainly  a notable  and 
practical  function  to  be  included  in  the  highest  level,  it  does  not 
have  to  be  included  in  all  architectures. 

From  the  above,  a three  level  hierarchy  appears  to  be  a 
natural  structure  from  which  to  start  the  Phase  II  process.  However, 
the  process  described  below  can  be  extended  to  include  hierarchies 
with  more  than  three  levels  if  necessary.  Reasons  to  consider  more 
than  three  levels  would  be  motivated  by  potential  savings  in  cost  or 
improvement  in  performance.  Such  potential  should  become  obvious  after 
analyses  of  the  three  level  structure  have  been  completed.  The  tools 
that  will  be  used  in  Phase  II  to  assign  hierarchies  to  logical  archi- 
tectures will  build  upon  and  take  advantage  of  the  relationships  of 
functions  within  the  logical  architectures.  The  goal  of  Phase  II  is 
not  to  enumerate  all  possible  groupings  in  a combinatorial  sense  but 
to  identify  those  groupings  which  are  promising. 

A procedure  by  which  logical  architectures  are  assigned  to 
hierarchies  is  given  below.  It  involves  two  steps.  The  first  step 
is  to  examine  each  of  the  functions  in  the  logical  architecture  individ- 
ually and  assess  its  applicability  to  and  feasibility  for  each  of  the 
hierarchical  levels.  During  this  assessment,  weights  could  be  assigned 
to  indicate  the  relative  applicability  of  each  function  to  each  of  the 
hierarchical  levels.  The  second  step  is  the  identification  of  the  most 
desirable  or  most  feasible  hierarchical  grouping  or  groupings  for  each 
logical  architecture.  A dynamic  programming  approach  can  be  used  to 
select  the  most  highly  weighted  hierarchical  grouping  for  each  archi- 
tecture. The  qualitative  factors  of  engineering  judgment,  design 
guidance,  and  technical  feasibility  will  determine  the  relative  order- 
ing or  weighting  of  hierarchical  levels  for  each  function.  The  grouping 
of  functions  into  a hierarchy  can  then  be  done  for  each  logical  archi- 
tecture on  the  basis  of  these  weightings. 

The  development  of  weights  for  each  hierarchical  level  must 
be  done  on  a function-by-function  basis  because  of  the  many  qualitative 
factors  involved.  For  example,  the  switching  function  could  certainly 
be  allocated  to  each  of  the  hierarchical  levels  on  the  basis  of  tech- 
nical feasibility  alone.  However,  the  assignment  of  switching  to  the 
lowest  level  could  have  advantages  or  disadvantages  in  terms  of  engi- 
neering design,  user  acceptance,  or  total  system  cost  which  are  out- 
weighed by  assigning  switching  to  a higher  level.  Thus,  instead  of 
assigning  equal  weights  of  0.33,  0.33,  and  0.33,  which  might  be  indi- 
cated by  technical  feasibility  alone,  a different  unbalanced  weighting 
of  0.2,  0.5,  0.3  might  be  assigned  due  to  the  other  qualitative  factors. 
On  the  other  hand,  a function  such  as  addressing  could  be  considered 
to  be  realistically  assigned  to  only  the  two  lower  levels  which  could 
indicate  a weighting  of  0.6,  0.4,  0.0. 
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The  second  step  involves  the  selection  of  a viable  grouping 
of  functions  for  each  architecture  on  the  basis  of  the  relative 
weighting.  A simple  hypothetical  example  is  shown  in  Figure  9.  In 
this  example,  the  logical  hierarchy  is  a string  and  the  maximum  total 
weight  exists  for  the  grouping  of  A and  B in  level  I,  C and  D in 
level  II,  and  E in  level  III.  This  grouping  could  be  determined  by 
computing  the  weights  of  all  combinations  and  selecting  the  largest. 

This  process  can  also  be  treated  as  a multistage  decision  process  where 
each  stage  corresponds  to  a function  in  the  logical  architecture, 
and  a decision  must  be  made  as  to  which  hierarchical  level  it  should 
be  assigned.  In  this  form,  the  grouping  decision  process  can  be 
treated  with  a dynamic  programming  algorithm  which  selects  the  most 
heavily  weighted  grouping  with  fewer  computations  than  exhaustive 
search. 

It  is  possible  that  the  selected  hierarchical  group  will  in- 
clude only  two  or  one  of  the  levels  rather  than  all  three.  If  the 
weightings  of  the  functions  are  such  that  the  maximum  group  weighting 
occurs  when  all  functions  are  included  in  the  lowest  level,  then  the 
selected  hierarchy  has  only  one  level.  Similarly,  if  the  selected 
grouping  has  no  third  level,  then  a two-level  hierarchy  is  the  approp- 
riate hierarchy.  Should  there  be  a fourth  level  or  additional  levels 
identified  during  the  weighting  development  process,  they  can  be 
handled  in  the  same  decision  structure  with  the  additional  levels 
included. 

★ * ★ ★ 

After  the  logical  architectures  have  been  assigned  to  hierarchies, 
the  functions  included  in  Phase  II,  i.e.,  those  in  Figure  8,  can  be 
assigned  to  the  stratified  logical  architectures.  This  procedure  is 
similar  to  the  two-step  procedure  used  to  assign  the  logical  archi- 
tectures to  hierarchies.  The  set  of  function  allocation  alternatives 
for  the  Phase  II  functions  must  be  defined  and  a set  of  relative  weights 
developed.  The  difference  here  is  that  the  allocation  and  weighting 
procedure  depends  on  which  stratified  logical  architecture  is  under 
consideration. 

A flow  chart  of  the  entire  process  for  Phase  II  is  given  in 
Figure  10.  A feature  of  this  approach  is  that  it  allows  sensitivity 
analyses  to  be  performed.  This  provides  a means  to  gauge  the  effect 
of  changes,  such  as  new  technology,  qualitative  insights,  and  the  like. 
Also,  the  sensitivity  of  the  selected  groupings  to  the  weights  assigned 
to  each  function  should  be  determined  before  proceeding  with  other  phases 
of  the  methodology. 
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Figure  9.  Example  of  Hierarchical  Weightings  For 
Each  Function  in  a Logical  Hierarchy 


4.  PHASE  III  - SYSTEM  ARCHITECTURES 


a.  Definition.  The  third  phase  in  the  methodology  is  the  develop- 
ment of  system  architectures.  A system  architecture  is  defined  to  be 
the  architecture  that  results  from  the  allocation  of  functions  within 
the  hierarchical  levels  of  a functional  architecture  to  specific  system 
elements.  A system  element  is  a conceptual  entity,  either  hardware  or 
software,  which  is  responsible  for  some  subset  of  functions.  Moreover, 

a system  element  involves  direct  connection  between  the  logical  rela- 
tionships examined  in  earlier  phases  and  the  physical  world  in  which 
the  eventual  network  architecture  will  operate.  A system  architecture 
consists  of  system  elements,  the  hierarchy  into  which  they  are  con- 
figured, the  functions  they  perform,  and  the  relationships  they  have 
with  each  other. 

Prior  to  the  definition  of  system  elements,  functions  not 
considered  earlier  and  which  apply  most  appropriately  in  this  phase 
are  integrated  into  the  functional  architecture.  Additionally,  the 
system  development  process  requires  the  consideration  of  physical 
environment  factors. 

b.  Additional  Functions.  Several  functions  have  been  identified 
as  being  more  appropriately  considered  in  the  system  architecture 
rather  than  in  previous  architectural  stages  because  they  depend 

more  on  system  level  considerations.  A list  of  such  functions  is 
given  in  Figure  11 . 

For  example,  not  all  of  the  functions  required  for  end-to-end 
security  have  been  considered  prior  to  Phase  III.  The  recommendation 
of  security  techniques  and  encryption  algorithms  is  not  possible  until 
a preferred  security  philosophy  is  developed  for  IAS.  However,  such 
functions  as  encryption/decryption  and  key  variable  distribution  are 
extremely  important  at  the  system  level.  These  functions  will  be  con- 
sidered when  system  element  responsibilities  and  relationships  are 
examined. 


System  management  and  control  functions  have  also  not  been 
considered  in  prior  phases  because  system  control  concepts  depend  more 
on  system  hierarchies  and  system  elements  than  on  logical  or  functional 
architectures.  In  Phase  III,  system  control  functions  will  be  included 
in  the  functional  hierarchies  and  assigned  to  system  elements. 

c.  Physical  Environment.  The  physical  environment  in  which  the 
eventual  network  will  operate  depends  on  several  different  factors. 
These  factors  include  the  number  and  type  of  users,  computer  technology 
and  communications  technology.  Each  of  these  factors  is  important  in 
determining  the  types,  responsibilities  and  relationships  of  system 
elements  for  a system  architecture. 
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Concentration 
Multiplexing 
Security  Processing 
Key  Variable  Distribution 
Network  Control 
Traffic  Control 
Status  Monitoring 
Data  Base  Maintenance 
Message  Switching 
Packet  Switching 
Circuit  Switching 
Encryption/Decryption 
Error  Control 


Figure  11.  Phase  III  Functions 
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Computer  technology  is  a key  factor  because  many,  if  not  all, 
of  the  functions  will  require  information  processing  and  computational 
power.  Computer  miniaturization  and  packaging  are  contributing  to  the 
more  frequent  application  of  modular  hardware  equipments.  Higher  order 
languages  and  structured  programming  techniques  are  making  the  develop- 
ment of  modular  software  more  efficient.  With  these  developments  the 
packaging  of  functions  into  system  elements  on  an  incremental  and 
modular  basis  is  feasible.  Thus  the  alternatives  in  terms  of  the  dif- 
ferent combinations  of  functions  per  system  element  can  be  varied  and 
numerous. 


Communications  technology  is  a contributor  to  the  possible 
system  element  configurations  because  of  modern  techniques  in  switching, 
multiplexing,  transmission  and  signaling.  Each  of  these  areas  will 
affect  the  decisions  made  in  Phase  III  and  in  Phase  IV.  The  major 
effect  in  Phase  III  will  be  on  the  relationships  of  system  elements 
and  on  the  processing  functions  required  to  support  the  various  com- 
munications techniques. 

The  numbers  and  types  of  users  will  affect  system  element 
selection  in  several  ways.  The  need  for  multiplexing  or  concentration, 
the  flexibility  required  in  message  processing,  the  access  techniques 
required  are  examples  of  areas  where  system  elements  will  be  affected. 

d.  System  Element  Assignments.  After  the  additional  system  level 
functions  have  been  included  in  the  functional  hierarchies,  the  assign- 
ment of  functions  to  system  elements  is  the  next  step  in  the  system 
architecture  process.  The  function  allocation  will  be  made  against  a 
list  of  system  elements  with  generic  names.  A list  of  such  elements 
is  given  in  Figure  12. 

The  elements  suggested  in  Figure  12  are  derived  from  several 
basic  groupings  of  functions  which  have  naturally  or  logically  evolved. 
For  example,  switching  nodes  are  easily  identifiable  because  of  their 
major  role  in  network  topology  and  because  of  the  significant  amount 
of  resources  required  to  perform  the  switching  function  for  a network 
with  thousands  of  users.  The  type  of  switching  which  is  required 
determines  the  nature  of  the  system  element  for  switching. 

A gateway  is  an  important  element  because  it  represents  the 
functions  required  for  one  network  to  interoperate  with  other  dis- 
similar networks.  It  can  be  considered  a distinct  system  element 
because  there  are  geographical  as  well  as  functional  considerations 
involved.  The  location  and  sizing  of  a gateway  as  well  as  the 
hierarchical  level  in  which  it  resides  are  issues  in  final  network 
design. 


Access  nodes  are  system  elements  which  provide  intermediate 
services  between  users  and  higher  levels  of  the  network.  The  existence 
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and  responsibilities  of  an  access  system  element  depend  on  the  hier- 
archical structure  of  the  architecture  as  well  as  the  functions  re- 
quired for  access  to  other  parts  of  the  network. 

Network  control  nodes  generically  represent  the  element 
required  to  control  the  network  when  implemented.  The  type,  functional 
responsibility,  and  hierarchical  location  depends  as  much  on  the  system 
control  philosophy  as  on  the  system  architecture. 

A centralized  service  facility  represents  an  element  that 
performs  the  functions  required  by  many  of  the  services  the  system  is 
to  provide.  Many  of  the  message  processing  functions  could  reside  in 
this  element  as  well  as  those  functions  required  to  support  sophisticated 
services  such  as  word  processing  and  electronic  mail.  This  facility  will 
be  heavily  dependent  on  computer  processing  capabilities. 

Key  distribution  centers  are  required  primarily  by  the  security 
functions.  For  a system-wide,  end-to-end  security  capability,  one  or 
several  key  distribution  centers  might  be  required.  The  exact  nature 
of  the  centers  and  the  degree  of  automation  required  will  be  determined 
by  the  security  philosophy  adopted. 

Multiplexers  and  concentrators  are  elements  which  have  evolved 
from  the  need  to  maximize  the  efficiency  of  the  usage  of  transmission 
resources.  These  elements  could  incorporate  more  functions  in  their 
responsibilities  in  some  cases. 

The  a priori  existence  of  a list  of  system  elements  does  not 
imply  that  all  system  elements  must  be  used  or  that  two  or  more  of  the 
system  elements  cannot  be  merged.  Rather,  the  list  represents  the  base- 
line set  of  elements  which  will  be  used  in  the  system  element  assignment 
process.  Analysis  of  the  architecture  might  suggest  a new  system  element 
which  would  amend  the  list. 

e.  System  Architecture  Selection.  The  procedure  for  identifying 
and  selecting  system  architectures  includes  the  assignment  of  functions 
to  system  elements,  determination  of  system  element  relationships,  and 
evaluation  of  system  architecture  feasibility.  A flow  diagram  of  this 
procedure  is  given  in  Figure  13. 

The  fundamental  architectures  from  Phase  II  have  to  be  modified 
with  the  inclusion  of  system  level  functions  as  described  in  Section  b. 
For  each  functional  architecture,  the  system  level  functions  must  be 
grouped  into  the  appropriate  hierarchical  levels.  As  the  system  func- 
tions are  applied,  there  may  be  more  than  one  modified  hierarchy 
possible  for  each  functional  hierarchy.  If  this  is  the  case,  tradeoffs 
might  be  established  and  a preferred  modified  hierarchy  selected. 
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System  Architecture  Selection 


The  next  step  is  to  assign  the  functions  in  each  of  the  modi- 
fied hierarchies  to  system  elements.  The  candidate  system  elements 
will  be  selected  from  the  list  of  system  elements  introduced  earlier. 

There  may  be  several  possible  assignments  for  each  modified  functional 
architecture.  Evaluation  criteria  will  be  developed  to  evaluate  and 
compare  the  alternatives. 

When  the  system  elements  for  each  modified  functional  archi- 
tecture have  been  applied,  the  relationships  of  the  system  elements 
can  be  determined.  From  this  determination,  the  architectures  which 
are  functionally,  operationally  or  technically  infeasible  will  be 
identified.  Those  architectures  that  remain  are  the  system  architectures 
to  be  examined  in  Phase  IV. 

5.  PHASE  IV  - NETWORK  ARCHIT\,TIJRE 

a.  Definition.  The  objective  of  this  architecture  methodology 
study  is  to  develop  a methodology  to  identify  and  select  a set  of 
candidate  IAS  architectures  that  can  be  analyzed  in  greater  detail  in 
terms  of  the  cost,  performance,  survivability,  and  reliability  trade- 
offs. The  definition  of  a network  architecture,  whose  components  are 
network  elements,  provides  the  framework  for  consideration  of  subjective 
issues,  policy  matters,  and  strategies. 

The  question  of  which  connectivity  policies  or  transmission 
media  models  should  be  considered  for  each  system  architecture  will  be 
partially  answered  by  analyses  carried  out  in  earlier  phases.  As  the 
various  types  of  architectures  are  selected  at  each  stage,  the  implica- 
tions concerning  issues  such  as  connectivity  policy  and  transmission 
media  will  be  more  clearly  determined. 

A network  architecture  is  defined  as  a system  architecture 
described  in  sufficient  detail  to  serve  as  a guide  to  implement  a 
communications  network.  This  involves  the  connectivity  policy  among 
network  elements  taking  into  account  the  geographic  distribution  of 
the  system  elements  and  transmission  media  types.  Thus  a network 
architecture  includes  topological  considerations  of  which  elements 
are  interconnected,  transmission  media  considerations  of  technology 
and  capacity,  cost  considerations  of  number  of  elements,  channels  and 
trunks,  traffic  considerations  of  number  of  users  and  throughput, 
and  performance  considerations  of  reliability,  survivability,  and 
availability.  To  determine  the  best  network  architecture  for  each 
system  architecture  on  the  basis  of  these  considerations  requires  an 
evaluation  and  selection  procedure  which  can  accommodate  connectivity 
and  media  policies.  It  is  recognized  that  the  number  and  location  of 
users  and  network  elements  and  traffic  requirements  for  the  IAS  will 
not  be  known  at  the  time  that  Phase  IV  is  performed.  Projections  and 
assumptions  can  be  made  for  these  factors,  however,  since  the  purpose 
of  the  evaluation  is  to  select  transmission  facility  types  and  general 
connectivity  policies  and  not  to  provide  a network  design  or  optimization. 
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b.  Selection  Procedures.  When  the  set  of  network  elements  has 
been  determined,  the  connectivity  can  be  studied  through  the  application 
of  one  of  several  techniques.  A number  of  heuristic  algorithms  are  avail- 
able for  this  purpose.  Models  of  the  projected  subscriber,  element  and 
traffic  distributions  and  transmission  facilities  will  be  developed  and 
one  of  the  algorithms  will  be  applied  to  the  models  to  the  extent  re- 
quired to  select  the  general  connectivity  policies.  Some  of  the  appli- 
cable algorithms  are  Branch  Exchange,  Concave  Branch  Elimination  and 
Cut-Saturation  (Refs.  [19]  - [21]). 

Each  of  these  algorithms  requires  an  initial  topological  con- 
dition which  generally  is  far  from  optimum.  Also  the  initial  condition 
will  depend  on  the  type  of  transmission  media  being  modeled.  A 
satellite-based  network  would  probably  look  very  different  from  a 
terrestrial -based  network.  In  order  for  any  of  the  search  algorithms 
to  be  appropriately  applied,  models  for  the  appropriate  transmission 
media  for  each  system  architecture  must  be  defined.  After  the  initial 
models  are  defined,  rules  for  substituting  branches  must  be  defined  to 
reflect  the  physical  nature  of  the  branches.  For  example,  if  branches 
are  being  added,  eliminated  or  exchanged,  the  range,  bandwidth  and 
vulnerability  of  the  branches  depends  on  whether  it  is  long  line 
terrestrial,  satellite,  microwave  or  high  frequency  (HF).  When  these 
models  and  rules  are  defined,  the  analysis  of  the  best  network  archi- 
tecture for  each  system  architecture  and,  therefore,  the  best  network 
* t architectures  overall  can  proceed. 

A flow  diagram  of  the  process  for  Phase  IV  is  given  in 
Figure  14.  The  result  of  Phase  IV  will  be  a set  of  candidates  net- 
work architectures  that  can  be  evaluated  in  more  detail  to  determine 
the  preferred  IAS  architecture. 
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IV.  METHODOLOGY  SUMMARY 


A graphic  description  of  the  methodology  is  given  in  Figure  15. 
Two  types  of  effort  pervade  the  methodology.  One  type  is  based  on  a 
well-defined  structure  for  the  definition,  generation  and  optimization 
of  alternatives.  It  includes  algorithms  which  are  automatable.  The 
other  type  involves  less  tangible  elements  such  as  issues,  policies, 
assessments  and  judgments.  This  type  is  not  directly  automatable,  but 
has  an  impact  on  the  automatable  portions. 

The  1990  IAS  architecture  is  a response  to  a need  defined  by 
system  and  user  requirements.  Capabilities,  services,  and  information 
transfer — the  requirements- -translate  into  a functional  baseline  which 
drives  alternative  generation.  The  four-phase  approach  incorporates 
technological  factors,  physical  characteristics,  and  subjective  con- 
siderations into  a structure  for  identification  of  a complete  space  of 
possibilities. 
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Figure  15.  Architecture  Methodology  Overview 
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APPENDIX  A 

MATHEMATICAL  CONCEPTS 

This  appendix  contains  terminology,  concepts,  and  definitions  for 
grammars  and  automata.  Examples  are  presented  to  illuminate  the  con- 
cepts. For  further  details  on  the  formal  aspects  of  trees  see 
Reference  [17]. 

In  a tree  system,  the  basic  notions  are: 

Tree  domain 
Stratified  alphabet 
Tree 
Term 

Regular  system  or  tree  grammar. 

The  following  definitions  present  the  theoretical  foundation  for 
these  terms: 

Definition  3.1.  Let  N+  be  the  set  of  positive  integers  and  U be  the 
free  monoid  generated  by  N+  with  identity  0 and  operation  " The 
depth  of  a«  U is  denoted  d(a)  and  defined  by: 

d ( 0 ) = 0 

d( a • i ) = d(a)  + 1 , icN+ 

Write  a*b  if  there  exists  xfU  such  that  a*x  = b.  Elements  a and  b are 
incomparable  if  a^b  and  b^a.  This  partial  ordering  on  U,  called  the 
universal  tree  domain,  is  illustrated  below: 


A-l 


0 


1 1 
; 


,i 


>■ 


1 2 3 


/ \ 

1.1  1.2 

/ \ 

'1.1.1  1.1.2  ... 

Definition  3.2.  D is  a tree  domain  iff  D is  a finite  subset  of  U which 
satisfies 

(1)  b«D  and  a<b  implies  a<D,  and 

(2)  a-j€D  and  i<j  in  N+  implies  a-ieD. 

A labeled  tree  will  be  defined  as  a mapping  from  a tree  domain  into 
some  set  of  symbols.  However,  only  trees  of  a certain  type  will  De 
considered;  to  this  end,  introduce  a stratified  alphabet. 

Definition  3.3.  A stratified  alphabet  (also  called  ranked  or  graded 
alphabet)  is  a pair(V,  r)where  V is  a finite  set  of  symbols  and  r:V-N, 
where  N = h+u|o}.  For  xev,  r(x)  is  called  stratification  of  x.  Let 
Vn  = r-1(n). 

Definition  3.4.  A tree  over  (V,r)  is  a function  <*:D^V  such  that  D is 
a tree  domain  and  r[« ( a ) ] = maxji I a- i< D( . That  is,  the  stratification 
of  a label  at  a must  be  equal  to  the  number  of  branches  in  the  tree 
domain  at  a.  The  domain  of  a tree  is  denoted  Da.  Let  Ty  denote  the 
set  of  trees  over  V.  Note  that  trees  are  generalizations  of  strings. 
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Definition  3.5.  A term  t over  (V.r)  is  defined  as  t = x<V  . or  t = xt, ...t  . 

o l n 

where  xeV^  and  t^  is  a term  Ui<n.  Ty  is  the  set  of  terms  over  V. 

There  is  obviously  a one-to-one  correspondence  between  the  terms  over 
V and  the  trees  over  V. 

Example:  Let  V = | + ,~,p,q},  r(+)  = 2,  r{~)  = 1,  r(p)  = r(q)  = 0.  In 
this  case,  Ty  is  the  set  of  well -formed  formulas  of  the  propositional 

calculus  involving  one  or  two  statement  letters.  The  tree  «=  |(0,+),  (1,~), 
(1.1, p),  (2,q) },  is  usually  written 

+ 

/\ 

q 

/ 

P 

The  tree  a represents  the  expression  (~p)  + q.  This  can  also  be  represented 
in  a Polish  postfix  notation  as  p~q+.  Another  possibility  is  to  represent 
the  tree  « by  a string  +~pq  which  corresponds  to  Polish  prefix  notation. 

The  set  of  trees  over  V,  written  in  Polish  prefix  form,  is  called  the 
set  of  terms  over  V. 

Definition  3.6.  Let  a,b,b'  be  members  of  U such  that  b = a-b'.  Then 
b/a  = b*.  Note  that  b/a  is  not  defined  unless  a<b. 

Definition  3.7.  Let  <*<Tv  and  a<D^.  Let  <»/a  = |(b,x)|  (a-b,x)<  <*}.  Then  a/a 
is  the  subtree  of  a at  a and  a/a  occurs  at  a in  a. 

Definition  3.8.  Let  aeTy,  aeU.Then  a-a=  { ( b , x ) | (b/a,x)fa}. 
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Definition  3.9.  Let  aeD«,  a,ftel^.  Let  «t(a *-ft)  = |(b,x)e«  lb*a}ua-0. 
This  is  the  result  of  replacing  the  subtree  «/a  at  a by  the  tree  ft. 

Definition  3.10.  A regular  system  R or  tree  grammar  over  (Vy,r)  is  a 
system  (V,r',G, S)  which  satisfies  the  following  conditions: 

( V , r ' ) is  a finite-ranked  alphabet  with  V^cV  and  r'lVj  = r. 
The  elements  of  V - V^.  are  called  the  non-terminal  symbols  or 
variables.  The  variables  will  be  denoted  by  ,X2> . . . ,Xn  where  ny 
denotes  the  number  of  variables. 

G is  a finite  set  of  generators  (also  called  rules  or 
productions)  of  the  form  d>-*^  where  <D  and  v are  trees  over  ( V , r ' ) . 

S is  a finite  subset  of  Ty  whose  elements  are  called  the 
axioms,  where  Ty  is  the  set  of  trees  over  alphabet  V. 


* * * * 


In  the  general  case,  the  regular  system  R defined  above  generates 
trees  as  follows:  <r^/Ms  in  R if  there  is  a generator  in  G such 

that  '*/a  =d>  and  ft  =(*(&*  *),  That  is,  v>  is  a subtree  of  * at  a;  ft  is 

obtained  by  replacing  the  occurrence  of  $ at  a by'K  Denote  by  • -»/$ 
in  R iff  there  exists  a€D(«)  such  thata^./J.  Also  <*=*0  is  in  R iff 

either  a = ft  or  there  is  a finite  sequence  » • • • »<»mt  m>0  such  that 
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“ = “(^"l '***,'>am  =^in  R*  The  sequence  1S  called  a derivation 

of  p from  « and  m is  the  length  of  the  derivation.  « is  a derivation 
of  length  0 if  a =>a  for  all  aeT^. 

Definition  3.11.  L(R)=|a£T  | there  exists  Y es  and  Y -><*}  is  called 

VT 

the  language  generated  by  R over  the  terminal  elements  Vy. 

Definition  3.12.  A tree  grammar  R = (V,r‘,G,S)  over  (VT,r)  is  expansive 

* 9 

iff  each  generator  in  G is  of  the  form 


X1  •**  Xn 


where  xf  VT  and  X,,,X.,...,X  are  non-terminals, 
l u I n 

A theorem  is  given  in  Reference  17  which  shows  how  to  effectively 
construct  an  equivalent  expansive  grammar  for  any  regular  tree 
grammar. 

It  was  noted  above  that  there  is  a one-to-one  correspondence 
between  the  terms  over  V and  the  trees  over  V.  If  the  trees  generated 
by  the  regular  system  R are  expressed  as  terms,  in  either  postfix  or 
prefix  notation,  then  these  terms  form  a context-free  set.  It  is  also 
of  interest  to  note  that  the  sets  produced  by  the  regular  system  are 
recognizable  (i.e.,  accepted)  by  machines  which  are  generalizations  of 
the  usual  finite  automata.  This  also  provides  a useful  notation  for 
the  implementation  of  the  regular  system  generating  scheme  on  a 
digital  computer.  For  completeness,  the  following  definition  is 


included: 


Definition  3.13.  Let  ( V , r)  be  a stratified  alphabet,  where  V = jx] ,x2, . . .xk| . 
A finite  tree  automaton  over  V is  a system  M = (Q,t1 ,t2,...,tk,F)  where 


a.  Q is  a finite  set  of  states 

r{v  ) 

b.  For  each  i,  lsisk,  ti  is  a relation  on  Q i xQ,  and 


c.  Fcg  is  a set  of  final  or  accept  states.  If  each  ti  is  a function 
t. :Qr*xi * -Q,  then  M is  deterministic  (otherwise  non-deterministic). 

Example:  The  elements  V * { A,E,D,L,B,1 ,1 ,2,3 } in  the  tree  grammar 
(V ,r,G,S)  where  VT  = {A,E,I,D,L,B}  and  the  function  r is  specified  by 
r(A)  = 1 
r(E)  = 1 or  2 
r(D)  = 0 
r(B)  = 1 or  2 
r(L)  - 0 
r ( I ) = 0 
and  the  generators  are 


(a)  S >A 


(d)  2 >B 

3 


(b) 


(e)  2 


(c)  1 >E  (f)  3 >D 

1 

2 
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This  grammar  generates  trees  representing  logical  architectures  for 
a simple  communication  network.  The  terminal  symbols  are  interpreted 
as  follows: 

A - addressing 
E - encryption 
L - local  distribution 
B - backbone  switching 
D - decryption 
I - interface  (gateway) 

The  generation  process  begins  with  the  application  of  a generator 
containing  the  start  symbol  "S".  This  generator,  labeled  (a),  is 
followed  by  the  application  of  one  of  the  generators  which  rewrites 
the  variable  "1".  That  is,  the  generator  (b)  or  (c)  is  applied. 

The  generators  are  applied  until  the  tree  contains  only  terminal 
symbols.  Note  that  the  choice  of  generators  to  apply  represents  a 
decision  to  be  made.  An  example  of  an  architecture  produced  by  this 
grammar  is 

A E B D 

I 
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E 
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In  the  subsequent  discussion,  the  trees  are  simplified  to 
strings.  That  is,  the  stratification  of  each  element  in  V is  <1. 

This  is  a reasonable  assumption  for  modeling  logical  architectures, 
in  which  concurrent  functions  are  represented  by  serial  organizations. 

The  following  section  contains  the  definitions  required  to  define 
a weight  function  on  the  syntactic  structure  of  the  regular  system 
(Ref.  [16]).  Denote  by  Gx  the  generators  which  rewrite  variable  X 
so  that 

u Gx 

G Xev  - VT 

Definition  3.14.  For  each  XeV  - Vy,  introduce  a weight  distribution 
over  Gx  which  satisfies 

wg>°  geGx 

£“g  ’ 1 

where  the  summation  is  carried  for  all  g in  Gx> 

For  a given  generation  tree  T,  denote  by  G(T)  the  set  of  generators 
used  at  the  nodes  of  T taking  into  account  the  number  of  times  the 
generator  has  been  applied  (i.e.,  its  multiplicity).  Then  the  weight 
associated  with  the  tree  T is  given  by 


W(T)  = n wg 

where  the  factor  wg  appears  as  many  times  as  the  index  g occurs  in  the 
set  G(T),  and  the  product  is  carried  over  all  g in  G(T). 
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Definition  3.15.  For  an  arbitrary  string  creL(R)  the  weight  associated 
with  o is  given  by 

W(  a)  =£W(T) 

where  Tq  denotes  the  set  of  generation  trees  which  produce  the  strings 
a , and  the  summation  is  carried  over  all  trees  T in  Tg  . 

The  best  logical  architecture  is  defined  as  that  string  a which 
maximizes  the  weight  for  all  strings  a in  the  language  L(R).  The  com- 
putation which  might  be  required  in  the  generation  of  all  the  strings 
in  L(R)  might  be  formidable.  In  place  of  this  direct  approach  of 
generation  of  all  architectures  for  ranking,  the  following  may  be 
considered.  To  simplify  the  discussion,  assume  that  the  grammar  is 
unambiguous.  Then  the  generation  tree  for  each  string  is  unique  and 
W(  cr)  = w(T0  ) = n Wg , where  the  product  is  taken  over  all  g in  G(T). 
Then  the  weight  measure  can  be  denoted  w(X,X')  which  corresponds  to  the 
generator  for  variable  X rewritten  as  variable  X'.  In  the  case  of  the 
terminating  generator  the  weight  vector  w(X)  contains  the  corresponding 
weight  for  each  variable.  Then  the  weight  associated  with  a string  is 

given  by  W(  o ) = w(X.  ,X.  )-w(X.  ,X.  ) w(X.  ). 

H 1 2 12  3 m+1 

Since  the  derivation  is  unambiguous,  the  variable  sequence 

(equivalently,  the  sequence  of  states)  replaces  the  variables  and  the 

maximization  problem  for  the  best  architecture  has  the  form:  find 

i0,i, i to  maximize 

t i m 

m 

11  w(in’in+l) 
n=l 


■ 
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To  reduce  the  computational  work  to  solve  this  problem,  reformulate  it 
as  follows: 


m 

Let  L ( j ; k ) = max  n^.  w(in,in+1)  over  ij5ij+1 

where  i . = k and  i ,,  is  fixed.  Then  the  recursion 
j m+1 


‘Vl 


L(j  = l ;1 ) = max  { w(l ,k) - L( j ,k)| 
k 

is  used  to  produce  the  solution.  Denote  by  k(j,l)  the  index  for  which 

i 

L(j=l;l)  is  attained.  Then  using  L(m;l)  = w(l,m+l)  the  recursion  is 
I 

solved  for  the  successive  values  j=m,m-l , . . . ,2.  For  this  special 
case  outlined  above,  the  solution  is  developed  as  a dynamic  progi  amming 
problem.  This  is  based  on  the  Bellman  principle  of  optimality:  "An 
optimal  policy  has  the  property  that  whatever  the  initial  state  and 
initial  decision  are,  the  remaining  decisions  must  constitute  an 
optimal  policy  with  regard  to  the  state  resulting  from  the  first 
decision"  (Ref.  [18]). 

This  formulation  provides  efficient  determination  of  the  "best" 
logical  architecture(s).  Moreover,  it  permits  efficient  sensitivity 
analysis  to  be  carried  out  by  varying  the  weights  over  a critical 
range  of  values  to  observe  how  the  optimal  policy  is  affected  by  these 
changes. 
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